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REMARKS 

In the specification, paragraph [0038] is amended to correct a clerical error. 

Prior to entry of this response, Claims 1-26 were pending in the application, with all 
claims rejected. By this response, Claims 1,10, and 23-26 are amended. No claims have been 
added or canceled. Hence, Claims 1-26 are pending in the application. 

SUMMARY OF THE OFFICE ACTION 

Claims 1-16 and 18-26 were rejected under 35 U.S.C. § 102(e) as allegedly anticipated 
by Marchand ^Marchan<JT\ U.S. Patent No. 6,714, 515). Claim 17 was rejected under 35 
U.S.C. § 103(a) as allegedly unpatentable over Marchand in view of Schell et al. ("Scheir; 
U.S. Patent No. 6,314,520). 

THE REJECTIONS BASED ON THE PRIOR ART 
(I) Rejection Under 35 U.S.C. §102(e) 

(A) Independent Claims L 10, 24 and 25 

Claims 1, 10, 24 and 25 recite similar features and, therefore, are discussed as a group. 
Claims 1, 10, 24 and 25 are amended herein to further define some claim terminology in the 
body of the claims, and to recite functionality of respective corresponding embodiments 
described in the application as filed. Thus, no new matter is introduced in the application by 
way of these amendments. 

(i) Functional Overview of Embodiments of the Invention 

Generally, embodiments recited in Claims 1, 10, 24 and 25 involve a network 
operational support system, which comprises a set of programs designed to support various 
network management functions (e.g., monitoring, controlling and analyzing problems in a 
computer network). The operational support system is configured with "native policies" that 
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address certain operational state conditions of network systems that the operational support 
system supports. However, during operation, network systems transition between operational 
states and may at times be in a state that is not fully supported by the native policies. Thus, the 
operational support system is "policy-enabled" in that it interfaces with external policy 
management systems, i.e., policy management systems that are logically separate from the 
operational support system. 

The operational support system is capable of determining which policy management 
systems address conditions representing the operational state of the managed network system. 
The operational support system is capable of availing of executable policy programs provided 
by such policy management systems, which address certain conditions associated with certain 
system states. Pertinent executable policies are selected based on a "contract" that defines 
criteria that the executable policies must satisfy, in light of policy "views" that comprise 
policies that address corresponding operational states. The selected executable policies are 
retrieved from the policy management systems and executed by the operational support system, 
to implement the corresponding policies that address the conditions that represent the current 
network operational state. 

(ii) Overview of Marchand 

In Marchand, a radio network server (RNS) is modified to function as a policy server 
providing resource allocation rules in a wireless DP network. The RNS informs a Bandwidth 
Broker (BB) whether sufficient resources are available to satisfy requests for resources, and the 
BB either allows or denies such requests based on input from the RNS. Edge routers enforce 
policy decisions made by the BB. (Abstract). 

(iii) Differences between Marchand and claimed subject matter 
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Marchand is primarily directed to management of network bandwidth resources. 
Marchand does mention that bandwidth broker (BB) does not merely control bandwidth, but 
can cause installation of policies in the edge routers that enforce BB decisions (col. 4, lines57- 
64). However, the QoS that the BB tries to implement is network bandwidth related. By 
contrast, the operational support system (OSS) of the present application, which is designed to 
support various telecommunication network management functions , retrieves and executes 
executable policy programs from external policy management systems. Thus, the OSS is not 
directed to network bandwidth but to network management and support, such as monitoring, 
controlling and analyzing problems in a computer network. Furthermore, the OSS implements 
the policies imported from separate management policy systems, by executing such policies, 
rather than installing the policies on remote network components for execution. 

Claim 1 recites the following: 

in response to a network system state change, receiving one or more conditions 

that represent the current state of the network system; 
determining whether native policies within the operational support system address 

the one or more conditions; 
in response to determining that the native policies do not address the one or more 

conditions, 

comparing the one or more conditions to one or more conditions addressed 
by one or more policy views of respective one or more policy 
management systems that are logically separate from the 
operational support system; 

based on comparing, determining at least one particular policy 

management system that addresses the one or more conditions that 
represent the current state of the network system. 
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Marchand does not disclose similar logic in response to a network system state change . 
That is, Marchand does not disclose receiving conditions that represent the current operational 
state of the system, determining whether native policies address the conditions and, if not, 
comparing these conditions with specific conditions addressed by the external policy 
management systems, to determine particular policy management systems that specifically 
address the current network state as represented by the conditions. Marchand merely discloses 
management of a request to set up a third generation (3G) wireless IP network call {see, e.g., 
col. 3, lines 60-63). Albeit, Marchand does illustrate and briefly describe Simple Policy 
Services 42, an internal policy server for defining simple rules, and different types of policy 
servers: Media Policy Server 39, Application Policy Server 41 and RNS 21. However, to 
reiterate, Marchand simply does not disclose the specific foregoing "smart filtering" logic 
through which at least one particular policy view, from a particular policy management system, 
that specifically addresses the current network operational state as represented by the 
conditions, is determined . 

Furthermore, Marchand does not disclose the use of policy views , which comprise a set 
of required policies that address specific conditions representing the current network state, from 
the external management policy systems . From the policy views, selected executable policies 
are imported, in accordance with a contract from the policy view, where the contract defines 
criteria that the selected executable policies satisfy and governs selection and operation of such 
executable policies . 

Based on the foregoing, Marchand does not anticipate Claims 1, 10, 24 and 25. 
Therefore, withdrawal of the rejection of Claims 1, 10, 24 and 25 under 35 U.S.C. § 102(e) is 
respectfully requested. 
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(B) Independent Claim 23 

(i) Functional Overview of Embodiment of the Invention 

Generally, Claim 23 recites, inter alia, various steps associated with policy access 

points of a policy kernel that implements policy-enabled, contract-based management of an 

operational support system that comprises a set of programs designed to support various 

network management functions. Further, Claim 23 recites steps related to the "contract" (e.g., 

contract 250 of FIG. 2), as follows with emphasis added: 

causing a contract of the requested policy view to be initiated for the selection of 
executable policies from an external policy engine of the policy management 
system; 

causing the contract to apply environmental requirements to the selected 

executable policies to enable the selected executable policies to execute on 
the policy kernel ; 

causing the contract to apply dependency rules to two or more of the selected 
executable policies when the behaviors of the two or more selected 
executable policies are in conflict with one another . 

As described in paragraph [0030], each policy view comprises a contract and a set of 
required policies, where the contract provides a means for assuring that the requested policy 
view is provided and that the appropriate policies are exchanged between an external policy 
management system and policy kernel of operational support system. As recited in Claim 23, 
functions of the contract include (a) applying environmental requirements to enable the selected 
executable policies to execute on the policy kernel, and (b) applying dependency rules to 
resolve policy conflict issues. 

As described in paragraph [0034], environmental requirements identify or define one or 
more particular running components that may be required for particular executable policies to 
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be enabled by policy kernel. For example, one environmental requirement for a particular 
executable policy may be language compilation by a particular compiler. In this case, contract 
will run the required language compiler on executable policy in order to enable it to be executed 
by policy kernel. 

As described in paragraph [0035], contract contains a set of policy dependency rules 
regarding the handling of conflicts or dependencies between executable policies that are 
selected. When the behaviors of two or more executable policies are in conflict with one 
another, contract applies the policy dependency rules to the executable policies to resolve 
conflicts between executable policies prior to constructing the requested policy view and 
importing the executable policies by policy kernel. 

(ii) Differences between Marchand and claimed subject matter 

The passages of Marchand cited in the Office Action in support of the "apply 
environmental requirements" feature discuss that the amount of assigned bandwidth in packet- 
switched IP networks is not fixed and can be renegotiated, via the BB and a policy server, 
during a call. Renegotiating and changing network bandwidth for a call , during the call, is not 
the same as applying environmental requirements to enable the selected executable policies to 
execute on the policy kernel as recited in Claim 23. Because the "executable policies" are 
executable programs (e.g., software code), execution of such policies requires the code be in 
executable form and may require a particular runtime environment for execution in the policy 
kernel. Hence, the contract of Claim 23 enables the executable policies to execute in the policy 
kernel through application of "environmental requirements" associated with the selected 
executable policies. Marchand does not appear to discuss such "executable" policies, in the 
sense of machine-executable program code. Nor does Marchand teach or suggest such 
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activities in furtherance of ensuring that executable policy programs can actually execute in the 
execution environment, i.e., the policy kernel of the OSS in Claim 23. 

The passages of Marchand cited in the Office Action in support of the "apply 
dependency rules" feature discuss that the amount of assigned bandwidth in packet-switched IP 
networks is not fixed across domains carrying a call, and can be changed during the call, which 
may require mapping a requested Class of Service (e.g., Conversational) and a specific type of 
application (e.g., voice or video) to a specific SLA. Mapping a class of service and/or a type of 
network call to a service level agreement, is not the same as resolving conflicts between 
policies, as recited in Claim 23. Marchand does not resolve conflicts among policies being 
applied to the same network system, rather it determines which SLA should be applied based on 
a requested class of service, in view of the type of service requested . In other words, Marchand 
tries to ensure that a correct SLA is chosen based on the request , in order to service the request, 
but does not resolve conflicts between policies that are executed based on an actual current 
system state as represented by the one or more conditions . 

Based on the foregoing, Marchand does not anticipate Claim 23. Therefore, withdrawal 
of the rejection of Claim 23 under 35 U.S.C. § 102(e) is requested. 

(C) Independent Claim 26 

As shown above, Marchand does not disclose the use of policy views , which comprise a 
set of required policies that address specific conditions representing the current network state, 
from the external management policy systems. Further, Marchand does not disclose executable 
policies that are imported in accordance with a contract from the policy view, where the 
contract defines criteria that the selected executable policies satisfy and governs selection and 
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operation of such executable policies . Therefore, Marchand does not anticipate Claim 26, 
which is patentable over the cited references of record. 

(D) Dependent Claims 2-9, 11-16, and 18-22 

Claims 2-9 depend from Claim 1 and Claims 11-16 and 18-22 depend from Claim 10. 
Therefore, Claims 2-9, 11-6 and 18-22 are patentable over the references of record for at least 
the same reasons as the claims from which these claims depend. Furthermore, each dependent 
claim recites at least one additional feature that makes it independently patentable over the cited 
references of record. For example, each of Claims 6-8 and 19-21 recites features involving one 
or more of the environmental requirements and dependency rules, which are discussed above in 
reference to Claim 23. Due to the fundamental differences between the independent claims and 
Marchand previously discussed, further elaboration with respect to these additional features is 
foregone at this time. However, the rejection of the dependent claims is collectively traversed, 
and no statements of official notice or allegations of well-known features that may be present in 
the Office Action are stipulated to or admitted as prior art features, and the right to separately 
argue such features in the future is not disclaimed. 

Withdrawal of the rejection of Claims 2-9, 1 1-6 and 18-22 under 35 U.S.C. § 102(e) is 
requested. 

(D) Rejection Under 35 U.S.C. § 103(a) 
(A) Dependent Claim 17 

Claim 17 depends from Claim 10 and, therefore, is patentable over the references of 
record for at least the same reasons as the claim from which this claim depends. Due to the 
fundamental differences between Claim 10 and Marchand previously discussed, further 
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elaboration with respect to this dependent claim is foregone at this time. However, the rejection 
of Claim 17 is traversed, and no statements of official notice or allegations of well-known 
features that may be present in the Office Action are stipulated to or admitted as prior art 
features, and the right to separately argue such features in the future is not disclaimed. 
Withdrawal of the rejection of Claim 17 under 35 U.S.C. § 103(a) is requested. 



For the reasons set forth above, it is respectfully submitted that all of the pending claims 
(1-26) are now in condition for allowance. Therefore, the issuance of a formal Notice of 
Allowance is believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

Please charge any shortages or credit any overages to Deposit Account No. 50-1302. 



CONCLUSION 



Respectfully submitted, 



HICKMAN PALERMO TRUONG & BECKER LLP 
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2055 Gateway Place, Suite 550 
San Jose, CA 95110-1089 
(408)414-1080 
Facsimile: (408)414-1076 




Darci Sakamoto 
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